
United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 

Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
www.uspto.gov 



APPLICATION NO. 



FILING DATE 



FIRST NAMED INVENTOR 



ATTORNEY DOCKET NO. 



CONFIRMATION NO. 



09/655,596 



09/06/2000 



William F. Beausoleil 



34313 7590 I I/I 5/2005 

ORRICK, HERRINGTON & SUTCLIFFE, LLP 
IP PROSECUTION DEPARTMENT 
4 PARK PLAZA 
SUITE 1600 

IRVINE, CA 92614-2558 



POU9-2000-0048-USI 



9320 



EXAMINER 



VU, TUAN A 



ART UNIT 



PAPER NUMBER 



2193 

DATE MAILED: 11/15/2005 



Please find below and/or attached an Office commxinication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Office Action Summary 


Application No. 

09/655,596 


Appncant(s) 

BEAUSOLEILET AL 


Examiner 

Tuan A. Vu 


Art Unit 

2193 





The MAILING DATE of this communication appears on the cover sheet with the correspondence address 



Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timety filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) t^ONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, Isy statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timety filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)S Responsive to communication(s) filed on 22 August 2005 . 
2a)El This action is FINAL. 2b)n This action is non-final. 

3) n Since this application is in condition for allowance except for fomial matters, prosecution as to the nnerits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 

Disposition of Clainfis 

4) S Clainn(s) 1^4 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) 0 Claim(s) is/are allowed. 

6) S Claim(s) 1^ is/are rejected. 
?)□ Claim(s) is/are objected to. 

8) 0 Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 0 The specification is objected to by the Examiner. 

10) 0 The drawing(s) filed on is/are': a)n accepted or b)n objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
Replacement drawing sheet(s) including the correction Is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

11) n The oath or declaration is objected to by the Examiner. Note the attached Office Action or fonn PTO-152. 

Priority under 35 U.S.C. § 119 

12) n Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (0. 
a)n All b)n Some * c)^ None of: 

1 .□ Certified copies of the priority documents have been received. 

2. n Certified copies of the priority documents have been received in Application No. . 

3. n Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attachment(s) 

1 ) M Notice of References Cited (PTO-892) 

2) CH Notice of Draftsperson's Patent Drawing Review (PTO-948) 

3) □ Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 

Paper No(s)/Mail Date . 



4) n Interview Summary (PTO-413) 

Paper No(s)/Mail Date. . 

5) CH Notice of Informal Patent Application (PTO-152) 

6) □ Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 7-05) 



Office Action Summary 



Part of Paper No./Mail Date 200511 05 



Application/Control Number: 09/655,596 Page 2 

Art Unit: 2193 

DETAILED ACTION 

1 . This action is responsive to the Apphcant's response filed 8/22/2005. 

As indicated in Applicant's response, claim 1 has been amended. Claims 1-4 are pending 
in the office action. 

Claim Rejections - 35 USC § 112 

2. The following is a quotation of the second paragraph of 35 U.S. C, 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

3. Claim 1 is rejected under 35 U.S. C. 112, second paragraph, as being indefinite for failing 
to particularly point out and distinctly claim the subject matter which applicant regards as the 
invention. 

The term "external data" in claim 1 is a relative term which renders the claim indefinite. 
The term "external data" is not defined by the claim, the specification does not provide a 
standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be 
reasonably apprised of the scope of the invention. In the specifications, pg. 6, there is mention of 
external to and fi-om a main memory; and yet there is no specificity on what entities this 
externality of data is applicable to. There is no straightforward and precise teaching from the 
claim and the specifications as to enable one skill in the art to be apprised in terms of how this 
'external' characteristic is implemented or defmed with respect to the nearby entities recited in 
the claim, e.g. the processors, work station and the main module. In light of the best connotation 
gathered from the reading the disclosure, this 'external' limitation will be treated as though the 
data is external to the memory module. 

Claim Rejections - 35 USC § 103 
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4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 1-4 are rejected under 35 U.S.C. 103(a) as being unpatentable over Beausoliel et 
al., USPN: 5,551,013 (hereinafter Beausoliel) in view of Austin et al., USPN: 4,885,684 ( 
hereinafter Austin); and ftirther in view of Baker et al, USPN: 5,701,502 (hereinafter Baker). 

As per claim 1, BeausoUel discloses a emulation engine comprised of a plurality of 
modules, a work station external to the plurality of modules, and a bus for transferring data 
between the work station and said modules (Fig, 1,8), each of such modules including a plurality 
of processors and a module main memory accessible for data transfers during an emulation by 
each of such processors (e.g. col. 3, line 55-65; col. 5, lines 32-35; Fig. 3A-B), each of such 
processors having a control store to store a programmable sequence of emulation steps that 
define logic states for its processor (e.g. col. 4, lines 1-5; col. 6, lines 2-10; Fig. 9A, 1 lA), a 
method to allow data transfers between such module main memory unit and work station without 
interrupting an in-progress emulation {non-blocking - col. 8, lines 16-56; Fig. 5,7), comprising: 

compiling said programmable sequence of emulation steps to include, in at least one step, 
a blocking code, when the step is read from the control store (e.g. col. 10, line 64 to col. 1 1, hne 
29; Control Store - col. 5, line 39 to col. 6, line 18; Figs. 2-3 ), as a disable command between 
the plurality of said processors and main memory unit ( e.g. active, inactive - col. 6, lines 14-27, 
28-59 ); 
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decoding said blocking code (e.g. col. 12, Table 1- Note: decoding is inherent to 
encoding instructions; Fig. 2a-b; Fig. 3a-b - Note: control word field/bit extraction is equivalent 
to decoding instructions code); and 

transferring external data between said work station and module main memory (e.g. 
input to target system, emulation support facility- col. 3, lines 28-37 ; workstation - Fig. 8 - 
Note: workstation is equivalent to host computer coordinating the support facilities functions 
operable on the processor modules, e.g. data or instructions transfer) 

But Beausoliel does not specify a maintenance bus for transferring data between the 
workstation and processor modules. However, BeausoHel discloses latches and multiplexers to 
control data flow into or out of a given processor execution in the emulation logic; and path 
control bits multiplexing and changes for allowing concurrent data connection to support 
facilities in the emulation environment (e.g. col. 3, lines 28-37; col. 8, lines 16-56; Fig. 1, 2A, 
3A-B) as well as recompiling of code modification as a result of errors (e.g. col. 10, lines 37-43). 
In view of the teaching by Beausoliel to address errors and to maintain support the emulation 
changes in code, to have facilities to control data flow from a processor ( see Support facilities - 
Fig. 8), a need to maintain the memory is suggested. Austin, in a network of processing units 
simulation environment with emulation, programmability/debug and interprocessor 
communication/scheduling and management support (see cols. 4-13; col. 17, lines 22-46) 
analogous to that of the emulating network of Beausoliel such as to use software program for 
deploying/supporting the functionality of the distributed data processing, discloses a 
maintenance bus for both the processing elements and for the supervisor unit (e.g. EMB and TM 
bus - col. 6, lines 4-26) for update storage operations, and other off-line functions. In view of the 
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suggested teachings from Beausoliel's and Austin's from above, it would have been obvious for 
one of ordinary skill in the art at the time the invention was made to provide a maintenance bus 
as taught by Austin to Beausoliel's concurrent support facilities operable within the emulation 
execution and operations by the processing units of Beausoliel's system because this would 
provide a specialized communicating channel, e.g. bus, to support the maintenance operations as 
suggested by Austin without affecting or interrupting the main data flow used by the processing 
units of the emulation by Beausoliel, thereby obviate bus/memory contention issues and enhance 
fault prevention, efficiency. 

Nor does BeausoUel explicitly specify that in response to decoding blocking code, 
blocking transfers between the plurality of module processors and said module main memory 
units; and transferring data between the workstation and module memory units during such 
blocking from above; that said blocking code included in a emulation step thereby allowing 
external data to be transferred between said work station and said main memory; and blocking 
data transfers between said module processors and said main memory. However, BeausoUel' s 
disable command from decoding the MOP bit teaches disabling access by the processors to 
specific parts of memory. This implicitly discloses a blocking of transfer between the processors 
and the memory during an emulation step. 

Austin, in the system for supporting and deploying distributed processors via software as 
mentioned above, discloses the use of maintenance bus to support the operations of the 
processing modules (re col. 6, lines 4-26); and teaches, via the use of LOS ( Local Operating 
System), initialization, debug and error-related suspension operations within the emulating unit 
processors and/or recovery operations using such maintenance bus (e.g. col. 7, Unes 51-63; 
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suspension, minimal overhead - col. 12, line 47 to col. 13, line 7; maintenance bus, alternate 
paths - col. 9, lines 3-33, 42-50). The use of maintenance facilities to allow recovery of faulty 
modules and to prevent contention of memory access during such recovery or maintenance tasks 
or the use of a protocol implemented via control bits to reject or block memory access to bus- 
connected processors or requests was a known concept as evidenced herein with Baker. Baker, 
also in an environment to use software or microcode to integrate functions of a target system 
emulating processors based on a existing processor operating system to achieve fault-tolerant 
system analogous to the integrated development network using code simulation by Baker, 
discloses a maintenance bus and hahing of process communications between the faulty 
processing unit and the central operating system in response to decoding a request to handle a 
maintenance interrupt (e.g. lock-step -col. 1 19, line 4-53) and thereby invalidating of non-valid 
data transfer to memory (e.g. col 127, lines 3-23). Hence, in view of above-mentioned 
Beausoliel's teachings on support facilities and memory code recompiling; and Austin's use of 
maintenance bus in conjunction with Baker's scheme to suspend servicing of slave processing 
units memory requests for synchronization tasks as a result of a maintenance interrupt detection 
as mentioned above, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to implement code instructions as taught by Beausoliel so that when a 
blocking code is decoded, the transferring of data between processors and their memory units is 
blocked so that the maintenance bus is utilized in order to allow data be transferred from the 
maintenance dedicated workstation onto the main memory unit just as suggested by Austin and 
by the recovery synchronization calls by Baker for the same reasons as mentioned above in the 
rejection of the maintenance bus limitation and also because this would avoid further 
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contamination/incoherency of the processor memory when external data are written to their 
memory units, i.e. synchronized maintenance process as taught by Baker so to prevent further 
damaging to a memory. 

As per claim 2, Beausoliel does not specify the step of unblocking transfers between the 
module processors memory unit when such step is sequentially decoded next after a blocking 
code step. But in view of the combined teachings by Austin and Baker's teachings on 
suspending operations upon a failure detection (Austin: col. 7, lines 51-63; suspension, minimal 
overhead - col. 12, line 47 to col. 13, line 7; maintenance bus, alternate paths - col. 9, lines 3-33, 
42-50; Baker: lock-step - col 1 19, lines 12-24) as mentioned above, it would have also been 
obvious to add the step of unblocking after a decoded step of blocking has been completed to 
Beausoliel' s repetitive emulation process because the motivation would be that once the 
maintenance steps as suggested by Austin are completed, it would be necessary to resume the 
data transfer and communication between the processors and their memory unit or bus system in 
Beausoliel' s system in order to proceed on with the rest of the emulation. 

As per claim 3, BeausoUel discloses a repetitive cycle in decoding and emulating the 
program code (e.g. col. 12, lines 5-13) but fails to specify that the transferring of data step 
between module memory and workstation is repetitive. But in view of the rejection of such data 
transferring step as addressed in claim 1, the repetition of such data transfer would be inferred 
from the combined teachings by BeausoUel (repetitive emulation decoding) and Austin 
combined with Baker (maintenance bus, LOS, suspension and initialization operations) and the 
rejection as set forth above. 
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As per claim 4, Beausoliel discloses a repetitive cycle in decoding and emulating the 
program code (e.g. col. 12, lines 5-13) but fails to specify that the transferring of data step 
between modules memory units and workstation being followed by an unblocking step is 
repetitive. This limitation corresponds to the same limitation of claim 3 above; hence, in view 
of the combined teachings by Austin/Beausoliel/Baker and the rejection as set forth in claims 2, 
and 3 above, this limitation would have been obvious because of the rationale as set forth therein. 

Response to Arguments 
6. Applicant's arguments submitted 8/22/2005 with respect to claims 1-4 have been 
considered are not persuasive and in that respect, deserve some counter arguments. 
(A) Applicants have submitted that the Office Action as per 5/20/05 has interpreted 'work 
station' to mean a module processor and Beausoliel, Austin, and Baker alone or in combination 
do not teach the limitations of claim 1 as amended to clarify on work station and external data ( 
Appl. Rmks, pg. 5, 1^ 2^^ para; pg. 6, 2^^ para) and that Baker fails to disclose data transfer 
being blocked and allowing external data to be transferred between main memory and a work 
station located external to the modules ( Appl. Rmrks, pg 5 bottom, pg. 6 top). The Office action 
has interpreted blocking of data transfers as claimed only to the extent of closest interpretation 
possibilities permitted by the claim language. The blocking of data and the transfer of external 
data as recited amount to two main concepts: transfer between main memory and plurality of 
processors being blocked by a code; and such code allowing external data to be transferred 
between said work station and said memory module. In col. 10, line 64 to col. 1 1, Beausoliel' s 
disabUng command reads on denying —if not blocking — access to certain memory part that 
would otherwise be accessible had the control word in the control store be different. First, the 
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limitation referred to as * blocking transfer' is construed as a blocking that does not allow access 
of a main memory by the module processors for some memory type of operation ( e.g. data 
transfer) and the code decoding as taught by BeausoUel clearly reads on not enabling the module 
processors to perform data transfers to and from said memory module during any given 
emulation step involving the emulation context. Second, as for 'said blocking code . . . includes 
the blocking code thereby allowing . . . workstation , . . main memory', it is noted that the whole 
phrase as claimed entails that a control work station is allowed to effect data between the main 
memory, as opposed to the rest of the plurality of processors which are being emulated in a 
particular execution stage. As perceived from Figure 8 by Beausoliel, a work station with 
support facilities to interface with the emulation engine, to compile code to provide power 
sequencing or to load program as presented entails a need a necessary stage as to recompile code 
and to reload the recompilation back into the emulation memory (see col. 3, lines 28-37; col. 8, 
lines 16-56; Fig. 1, 2A, 3A-B; col. 10, lines 37-43), i.e. a required stage where code must be 
readjusted in the emulation engine, at which moment emulation must be necessarily stopped for 
new compilation be re-integrated in the Emulation system memory. As well known in circuitry 
equipped with maintenance facilities with maintenance work station and dedicated bus therefore, 
Austin has been set forth for the rational as to render why a maintenance work station can 
communicate with a main memory for such endeavor. Austin has been thus brought in to 
provide such maintenance bus, and finally. Baker's special error readjusting commands are used 
in order to fulfill BeausoUel' s need to maintain a memory during different emulation stages 
where code need to be recompiled to avert errors. The claim does not describe in more precise 
terms as to how such data transfer as recited would distinguish over the combined teachings by 
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Austin and Beausoliel in view of Baker's approach, i.e. why these teachings as put together 
would clearly fail to amount to the so-called limitation by which blocking of many processors 
and allowing only one processor to use the common memory is done. As construed by the claim, 
a maintenance bus is present in the course of stages of emulation, a bit detected so to allow only 
just one processor, or a maintenance dedicated machine to access a shared memory while 
preventing all target processors from accessing it due to a need for an maintenance operation that 
would require emulation to be interrupted. Based on BeausoUel's facilities and emulation system 
needs to update its compiled code, the motivation to provide a maintenance bus as via Austin and 
a special code by Baker to allow a process to correct memory contents while keeping other 
processes from further damaging it has been evident; and the reasons why the combination 
would have been obvious are set forth in the rejection. Besides, the 'external data' as claimed 
does not necessarily preclude data either from the workstation or from the module processors to 
be external data to the main memory so that the data are mutually exclusive of each other. 
(B) Applicants have submitted that Austin and Baker in view of BeausoUel's emulation 
method relate to completely different and unrelated technologies (Appl. Rmks, pg. 6, bottom 
para; pg. 7, 1^ para). There is no requirements in a USC 103(a) type rejection that the references 
being put together should come from exactly analogous fields of technologies; it is a particular 
aspect of a field or methodology for which a common endeavor is targeted, and the purpose in 
such endeavor being aimed at is what is at issue for providing a obviousness rationale, not the 
field within which such common endeavor and purpose is being set. The field is scheduling and 
controlling operations of multiprocessors environment, using a common memory accessible via a 
bus; and the endeavor for which a purpose is targeted is to provide a expedient and save way to 



Application/Control Number: 09/655,596 Page 1 1 

Art Unit: 2193 

correct the content of such memory to prevent further damage, e.g. maintenance operation, and 
not indefinitely disrupting the operation of the multiprocessor system. For obviousness rejection 
, the claim has to be treated as a whole; and the claim conveys the following. A decoding of a 
code and a timely permitting of one control processor to access a common memory which is to 
be updated while excluding the rest of the system processors under control; and that amounts to 
what is perceived from the interpretation of the claimed 'maintenance bus', 'blocking code', and 
'said blocking code and . . . blocking transfers between the plurality of . . . processors and thereby 
allowing . . . workstation . . . main memory' as mentioned above. Hence, the references by 
providing teachings combining a maintenance needs (Beausoliel), a bus (Austin) and exclusive 
access (Baker) for memory corrective needs have been set forward to provide the rationale as to 
why the claimed limitation as interpreted would have been obvious, notwithstanding the non- 
analogous fields of technologies as alleged by Applicants. If the claimed invention has to be 
treated as a whole such as has been shown above via broad reasonable interpretation, the 
rejection as set forth has to be treated in light of the combined teachings from all references 
including the inherent or suggested teachings thereof Thus, arguing that the references come 
from disparate fields or technologies amount to mere allegations without showing why the 
combined teachings fail to teach the claimed invention as interpreted; even by exposing deficient 
teachings in each reference taken individually, which would have been inconclusive in showing 
why these teachings fail to distinguish over the claimed invention. 

(C ) The Applicant has submitted that Beausoliel and Austin sought to address different 
problems ( Appl. Rmrks, pg. 7, top para). It appears from the argument that Beausoliel and 
Austin do not come from similar methodologies; and thereby there are insufficient grounds as to 
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why they can be combined. In response to applicant's argument that there is no suggestion to 
combine the references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention where 
there is some teaching, suggestion, or motivation to do so found either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art. See In re 
Fine, 837 F,2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re Jones, 958 F.2d 347, 21 
USPQ2d 1941 (Fed. Cir. 1992). Reinforcing what has been mentioned in section B above, it is 
further noted from the Beausoliel or Austin that an external control work station or central 
computer is there to provide control or resolving of issues encountered in the course of executing 
code and scheduling interaction between the plurality of processors being the target under 
control of such work station or central processors; and in the context of addressing operating 
problems in multi-processor emulation or multi-computer processing as seen in Beausoliel or 
Austin (or Baker), a need arises as to provide a channel ( e.g. maintenance facilities^us) via 
which maintenance operations initiated from said control station can be effectuated; and both 
BeausoUel and Austin (and/or Baker) have been cited to show such necessity; Austin to provide 
recompiled corrective code; Austin to provide to support distributed compilation and control 
thereof, and Baker to provide update/purge unwanted memory data to make optimized use of 
resources. 

In short, Applicants' argument about references not being analogous is not persuasive. 
That all the references presented should come from analogous fields of endeavor is not a strict 
requirement according to current rules and procedures governing USC 103(a) rejection. It is an 
application and/or useful methodology that needs to be addressed not the environment wherein 
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such methodology is being suggested or disclosed. Hence, by applying a motivation when 
combining the teachings from 3 references as set forth in the rejection, a prima facie case has 
been established; and the mere allegation that the references used come from 3 technologies does 
not amount to overcome the rationale as set forth in the rejection. 
The claims will stand as set forth in the rejection. 

Conclusion 

7. THIS ACTION IS MADE FINAL. AppUcant is reminded of the extension of time 
policy as set forth in 37 CFR L 136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The examiner can 
normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 
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The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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